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REMARKS 



In the Office Action dated June 5, 2003, claims 1-40 were pending. Claims 1-26, 28- 
30, 32-34, 36-40 were rejected under 35 U.S.C. 103(a) as being unpatentable over Stucka et 
al. (U.S. Patent No. 5,596,702) in view of Brittain et al. (U.S. 6,195,098). Claims 27, 31, and 
35 were rejected under 35 U.S.C. 103(a) as being unpatentable over Stucka in view of Brittan 
and Kahl et al. (U.S. Patent No. 5,936,625). 

In this response, no claim has been cancelled and no claim has been amended. 
Reconsideration of the present application is respectfully submitted. 

Rejections Under 35 U.S.C. § 103(a) 

Claims 1-26, 28-30, 32-34, 36-40 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Stucka in view of Brittan. 

To establish prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 
981, 180 USPQ 580 (CCPA 1974). (Manual of Patent Examining Procedure 
(MPEP) 12143.03). 

Applicant submits that claims 1-40 include limitations not disclosed or suggested by 
the cited references and they are patentable over the cited references. Specifically, 
independent claim 1 recites as follows: 

1 . A method comprising: 



extracting a first data from a display buffer of a video card , the first data generated 
by a first application and being associated with a user interface from the first 
application; 



recognizing a layout from the first data; and 



Application Serial No. 09/532,412 



-12- 



Atty. Docket No. 7445 LP1 15 



using the layout to create an overlay to display a second data generated by a 
second application, wherein there is no direct link between the first 
application and the second application. 

(Emphasis added) 

Applicant submits that independent claim 1 includes a limitation of extracting a first 
data from a display buffer of a video card , where the first data is generated by a first 
application and being associated with a user interface from the first application. This 
limitation is not disclosed or suggested by Stucka and Brittan, individually or in combination. 
The examiner contends that the section of col. 23 lines 62-67 and col. 24 lines 37-60 in 
Stucka reads on this limitation. Applicant respectfully disagrees. Applicant submits that 
Stucka discloses a user interface server (UIS) that provides user interface services to multiple 
applications in a form of a library via a specific API (application programming interface), 
similar to a software development kit (SDK), which is used by a developer of the respective 
application. The section of Stucka mentioned by the Examiner discloses how an application 
communicates with the UIS via a set of APIs, which must be compiled and linked (via a 
compiler and linker of a software development tool, such as a C/C++ compiler and linker) 
with the application when the application is developed by the developer, to access one or 
more functions provided by the UIS. See, for example, col. 20, line 33 to col. 21, line 40, and 
col. 22, line 58 to col. 23, line 55. Nowhere in Stucka discloses the limitation of extracting 
data from a display buffer of a video card in Stucka. In fact, there is no mention of extracting 
data from a display buffer in Stucka or Brittain. 

Even if, for the sake of argument, the access from an application to a UIS server can 
be considered as "extracting data" from a first application (e.g., UIS server is considered as a 
first application), the access to the UIS cannot be performed via a display buffer of a video 
card . As shown in Figure 3 of Stucka, the UIS is a server that is a dedicated system (e.g., a 
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standalone system) providing specific services over a network connection (e.g., connection 56 
of Figure 3), according to Webopedia.com. One skilled in the art would not attempt to store, 
even if it were possible, the UIS (e.g., a server), specifically the library, such as display object 
store 46, in a display buffer of a video card accessed by another application, such as 
application 50. Applicant submits that one with ordinary skill in the art would not believe a 
server or a library, such as display object store 46 of Stucka, would reasonably be stored in a 
display buffer of a video card. The Examiner stated that Brittain discloses a display buffer of 
a video card and it would be obvious to combine Stucka and Brittain. Applicant respectfully 
disagrees and for the reasons discussed above, Applicant respectfully submits that, in contrast, 
a person of ordinary skill in the art would not combine Stucka and Brittain, because such 
combination lacks reasonable successes, as discussed above. 

In addition, independent claim 1 includes a limitation of recognizing a layout from the 
first data extracted. Applicant submits that this limitation is also absent from the cited 
references, individually or in combination. Nowhere in Stucka or Brittain is there disclosure 
or a suggestion recognizing a layout from the data extracted from a display buffer of a video 
card , which is generated by another application. In fact, there is no mention of recognizing a 
layout in a display buffer in the cited references, individually or in combination. As discussed 
above, Stucka relies on a set of APIs used by an application to access a server to retrieve user 
interface data. There is no need to recognize a layout from the data provided by the UIS. The 
respective application has to be compiled and linked with the corresponding API, such as the 
header files and libraries of the UIS, during the development of the application. At run time, 
when the application calls a specific function (e.g., an API function) to access the server, the 
server provides services to the application. It is irrelevant whether the application would 
recognize a layout of the data returned from the server because the application has to call the 
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corresponding function exported and published by the server in a format required by the API, 
regardless of whether the application recognizes the layout. In contrast, the present invention 
as claimed recognizes a layout of a user interface generated by another application in a 
display buffer (e.g., about to be displayed or currently displayed) of a video card and overlays 
its data with the recognized interface. Therefore, one would not be motivated, based on the 
teachings of Stucka, to arrive at the present invention as claimed. 

Furthermore, independent claim 1 further includes a limitation of using the recognized 
layout to create an overlay to display a second data generated by a second application, 
wherein there is no direct link between the first and second applications. Applicant submits 
that this limitation is also absent from the cited references, individually or in combination. 
Applicant submits that Stucka fails to disclose or suggest using the recognized layout from a 
first application to create an overlay to display data from a second application. As discussed 
above, an application of Stucka has to rely on a set of APIs to access the UIS in order to 
create a user interface. Nowhere in the cited references disclose or suggest an operation of 
creating an overlay of a recognized layout, when an application accesses the UIS via a set of 
APIs. There is no need or motive to create an overlay to display the data from another 
application, as discussed above. 

Further, the application accessing the UIS in Stucka cannot be considered not having a 
direct link with the UIS. Rather, Applicant submits that there is indeed a direct link between 
the application and the UIS in Stucka. The source code of an application in Stucka must be 
compiled and linked with the exported or published APIs from the UIS. Any changes in the 
APIs would cause the communications between the application and the UIS to fail, which 
requires either the application or the UIS, or the both to be recompiled and linked. The 
applications and the UIS of Stucka depend on a set of APIs mutually agreed upon, which 
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teaches away from the present invention as claimed. See, for example, col. 23, lines 38 to 54. 
Therefore, there is a direct link between an application and the UIS in Stucka. In contrast, 
there is no direct link between the first and second applications in the present invention as 
claimed. Therefore, for the reasons discussed above, independent claim 1 is patentable over 
the cited references. 

Similarly, independent claims 9, 17, 25, 29, 33, and 37 include limitations similar to 
those discussed above. Therefore, for reasons similar to those discussed above, independent 
claims 9, 17, 25, 29, 33, and 37 are patentable over the cited references. 

The rest of the claims depend on one of the above independent claims, thus include all 
of the distinct features of the respective independent claim, and therefore, for the reasons 
similar to those discussed above, are patentable over the cited references. Withdrawal of the 
rejections is respectfully submitted. 
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CONCLUSION 



In view of the foregoing, Applicant respectfully submits the present application is now 
in condition for allowance. If the Examiner believes a telephone conference would expedite 
or assist in the allowance of the present application, the Examiner is invited to call the 
undersigned attorney at (408) 720-8300. 

Please charge Deposit Account No. 02-2666 for any shortage of fees in connection 
with this response. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN 





Kevin G. Shao 
Reg. No. 45,095 



12400 Wilshire Boulevard 
Seventh Floor 

Los Angeles, California 90025-1026 
(408) 720-8300 
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